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INTEGRATIVE RISK MANAGEMENT SYSTEM AND METHOD 

The present invention relates to an integrative risk management 
system and a method thereof and particularly, but not exclusively, to a risk 
5 management system in which the risks arising from a plurality of separate, 
but related, projects can be automatically managed in a centralised 
manner. 

Risk management fundamentally consists of assigning to a nested 
structure of projects and their associated activities at least a cost and a 

10 time and then identifying risks and the impact of such risks on the cost and 
time assigned to each particular activity and project. The same risk could 
affect more than one activity or project but may have differing levels of 
impact. Where a risk has an impact on the cost of an activity, for example, 
then the analysis can be performed against each activity independently. If, 

15 on the other hand, a risk has an impact on time, then the analysis of the 
impact must feed through the entire project structure. For each risk that is 
identified, mitigating plans are identified and put in place to reduce or 
prevent the risk. The mitigating plans are generally in the form of a series 
of actions that are to be followed. The mitigating plans could have the 

20 effect of reducing the probability of the risk arising or of reducing the extent 
df the risk's impact on a particular activity or project. 

Increasingly, companies are turning to risk management to identify 
and irnplement ways of reducing their exposure to risk, especially in large- 
scale projects. Various risk management software products have been 

25 developed to assist in this, much of the software being specifically for use 
in risk management in the medical field. Development of risk management 
systems has focused on ways of automating the analysis of risk and 
identification of mitigating actions. For example, US5930762 describes risk 
management software which is capable of automatically identifying 

30 appropriate mitigating actions in response to an identified risk. However, 
commonly, those having responsibility for the management of risk in large 
scale projects have not been part of the day-to-day management of the 
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projects involved. As a result, risk management software has remained a 
stand-alone software product. 

Especially for large-scale projects, it has been realised that the 
separation of risk management and project management is not ideal. 
5 Firstly, such separation results in unnecessary duplication of work. More 
importantly, where there is a separation of risk management and project 
management, poor communication can result in changes in a project not 
being accommodated in the modelling of the risk for that project and in 
actions, identified as best mitigating a risk, not being implemented in the 
10 project. 

The present invention therefore seeks to provide an integrative risk 
management system that overcomes at least some of the disadvantages 
outlined above and in particular is capable of integrating with project 
management systems. The present invention is especially, but not 

15 exclusively, concerned with providing a risk management system and 
method that is suitable for use with multiple projects at multiple sites, 
remote from one another. 

The present invention provides risk management software 
comprising a set of instructions for the following steps to be performed 

20 when the software is executed: 

a) accessing project data consisting of a plurality of actions to be 
performed; 

b) analysing the project data to identify a plurality of activities to at 
least some of which is assigned at least one risk indicator; 

25 c) on the basis of one or more mitigating tasks identified to reduce 

or prevent a risk or the consequences of a risk, outputting to the 
project data one or more new actions or alterations to existing 
actions in the project data; and 
d) accessing changes to the project data and revising the plurality 
30 of activities in dependence on whether the changes are to 

actions in the project data resulting from step c) above. 
Preferably, the changes to the project data are compared with new 
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actions or alterations to existing actions previously output to the project 
data and where the changes to project data relate to actions previously 
output to the project data no revisions are made to the plurality of activities. 
Moreover, the software may receive a trigger from the product data so that 
5 it knows when the project data has been changed. Alternatively, the 
software may periodically poll the project data to determine whether 
changes have been made to the project data. 

In a preferred embodiment the risk management software comprises 
the further step of automatically outputting a message to a predetermined 
10 recipient when the consequences of a risk are identified as exceeding a 
selected threshold. Also a message may be automatically output to one or 
more predetermined recipients when the processor receives notice of an 
impacted risk. 



15 apparatus comprising a risk processor; means for linking the risk processor 
to a risk data store; a project data interface for linking the risk processor to 
a second store containing project data; and a program store containing a 
set of instructions for performing the following functions: 



In a further aspect the present invention provides risk management 
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a) accessing project data in the second store, the project data 
consisting of a plurality of actions to be performed; 



b) analysing the project data to identify a plurality of activities to at 
least some of which is assigned at least one risk indicator and 
storing the plurality of activities in the risk data store; 



25 



c) on the basis of one or more mitigating tasks identified to reduce 
or prevent a risk or the consequences of a risk, outputting to the 
second store one or more new actions or alterations to existing 
actions in the project data; and 
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d) accessing changes to the project data and revising the plurality 
of activities stored In the risk data store in dependence on 
whether the changes are to actions in the project data resulting 
from step c) above. 



Ideally, the risk data store and the second store utilise the same 
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database. Alternatively, a network interface may be provided for 
connecting to the second store when located at a remote site. 

Ideally, the functionality of the apparatus is divided into at least three 
parts: a presentational part for managing the presentation of risk 
5 information to a user of the apparatus; a logic part for analysing the project 
data and for generating and updating the contents of the risk data store; 
and an interface part for enabling communication of the apparatus with 
external applications and wherein the presentational part and the interface 
part are restricted to only interfacing internally with the logic part. A fourth 
10 part may be included consisting of a risk data store interface which is 
permitted to interface with both the logic part and the interface part. 

In a third aspect the present invention provides a risk management 
method for storing and updating risk information, comprising the steps of: 

a) accessing project data consisting of a plurality of actions to be 
15 performed; 

b) analysing the project data to identify a plurality of activities to at 
least some of which is assigned at least one risk indicator; 

c) on the basis of one or more mitigating tasks identified to reduce 
or prevent a risk or the consequences of a risk, outputting to the 

20 project data one or more new actions or alterations to existing 

actions in the project data; and 

d) accessing changes to the project data and revising the plurality 
of activities in dependence on whether the changes are to 
actions in the project data resulting from step c) above. 

25 Thus, with the present invention, it is possible for risk to be managed 

from a central system which automatically accesses and utilises project 
management data on a global basis, therefore making it suitable for use 
with projects involving a consortium of different enterprises. Furthermore, 
the integrative risk management system of the present invention is capable 

30 of being proactive with respect to changes in the one or more projects for 
which risk is being managed. 

An embodiment of the present invention will now be described by 
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way of example with reference to and as shown in the acconnpanying 
drawings, in which: 

Figure 1 is a schennatic illustration of an integrated project 
management and risk management system; 
5 Figure 2 is a schematic overview of the system architecture of an 

integrated project management and risk management system in 
accordance with the present invention; 

Figure 3 schematically illustrates the interfaces between the various 
functions of the risk processor of Figure 2; and 

10 Figure 4 illustrates a systems architecture for a risk management 

system in accordance with the present invention. 

With reference to Figure 1, in large-scale implementation of the risk 
management system for example for a multi-national company, in practice 
the risk management system 1 including a risk processor 2 will be at a first 

15 location, for example head office, and in communication with a risk data 

store 3 which is either part of the same machine as the processor 2 or may 
be elsewhere, in which. case communication of the processor 2 with the 
data store 3 is via a communications link which may be, for example, a 
LAN or WAN. A large number of workstations, away from the first location, 

20 would also be capable of communication with the risk processor 2 via 

similar communications links, or via the web. Preferably, each workstation 
has a standard web browser to enable the workstation to interrogate the 
risk management system and obtain risk information from the risk data 
store 3. Additionally, at least some of the remote workstations include 

25 project management systems 4 in which project data in the form of a series 
of nested actions is stored along with information on the status of the 
actions. 

The integrative data management system 1 is able to automatically 
interrogate the project management systems 4 and retrieve the project 
30 data. This project data is used by the risk management system in the 

construction of a conventional activity breakdown structure which consists 
of the projects and their associated activities, ordered in a nested 
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arrangement, with a respective cost and time assigned to each project and 
activity, as mentioned earlier. The risk management system 1 is similarly 
capable of identifying and retrieving changes to individual managed 
projects and adjusting the activity breakdown structure accordingly. The 
5 identification and retrieval by the risk management system of changes to an 
existing managed project is described in greater detail below. 

All potential risks are then identified and the impact of the risks on 
the cost and time assigned to each activity and each project is determined 
along with suitable mitigating actions. The identification of risks and 

10 mitigating actions may be performed manually and the data entered into 
the risk management system or the risk management system may include 
functionality to identify risks and mitigating actions automatically. 

Once the mitigating actions have been identified and the risk for 
each project and activity adjusted to account for the implementation of 

15 mitigating actions, where appropriate, risk or mitigating action assignments 
are then automatically communicated by the risk management system, 
ideally via e-mail using an e-mail interface 6, to the relevant project 
managers via their remote workstations. As a result of these new 
assignments, individual projects may be altered resulting in changes to the 

20 project data. These changes, like all other changes to the managed 
projects are identified by the risk management system as mentioned 
above. However, where these changes reflect mitigating actions that were 
originally identified by the risk management system, the changes are not 
used to update the activity breakdown structure. This is necessary to avoid 

25 the development of a continuous loop of adjustments attracting further 
adjustments, and so on. 

The exchange of data between the project management system 4 
and the risk management system may be achieved by means of a mapping 
table 21 that may be stored with the risk management system 1. The 

30 mapping table 21 may additionally be used to record changes to the 

managed project. In this way a polling function may be implemented by the 
risk management system 1 to interrogate the mapping table on a regular 
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basis, e.g. once a day or once an hour to identify any new additions to the 
mapping table representing changes to the managed project. Any new 
additions that are identified are then read by the risk management system 
and compared against the mitigating actions and activities which are 
5 already known to the system. Where an addition is found to represent a 
change to a managed project that does not result from a mitigating action, 
the activity breakdown structure stored in the risk database 3 is updated to 
reflect the change. 

When an event that has been identified as a risk occurs, that is to 

10 say it is impacted, this is entered into the risk management system. The 
risk management system then automatically issues messages, ideally in 
the form of e-mail messages, to one or more people whose names are pre- 
programmed into the risk management system, for notifications of this 
nature. For example, the recipients of such automated messages may 

1 5 include the risk manager, the project manager of the project affected by the 
impacted risk and in the case of catastrophic risks a CEO or other senior 
director of the company managing the project would in all probability also 
be automatically notified. Filters can be defined in the risk management 
system to control when such messages are sent. Examples of such filters 

20 include: risk category, cost or risk owner (the person responsible for 
managing the risk and any mitigating actions). 

In Figure 2 an overview of the system architecture of an integrated 
project management and risk management system is shown. The system 
architecture 1 comprises risk register and analysis functions implemented 

25 in a risk processor 2, an activity and risk data store 3, which ideally stores 
the data in a relational database, one or more project planning functions 4, 
requirements management applications 5, communications applications 6 
and reporting applications 7. The risk processor 2 interfaces with each of 
the other system functions but the other system functions, with the 

30 exception of the reporting applications 7, are limited to interfacing with the 
risk processor. The reporting applications 7 additionally interface directly 
with the activity and risk data store 3 so that data can be read from the data 
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store and written into reports that are launched by the risk processor 2. 
The risk processor 2 and the data store 3 jointly connprise the risk 
management system 8. 

The project planning functions 4, requirements management 5, 
5 communications applications 6 and the reporting applications 7 may all be 
external third-party applications with which the risk processor 2 is capable 
of interfacing and hence integrating into a centrally controlled combined 
project management and risk management system. For example, the 
project planning functions 4 may be implemented using MS Project™, the 

10 requirements management 5 may be implemented in QSS DOORS™, MS 
Outlook/Exchange™ may be utilised as the communications applications 6 
and Seagate Crystal Reports™ may be utilised as the reporting application 
7. The above commercially available applications only exemplify the type 
of third-party applications that may be implemented with the integrative risk 

15 management system described herein. As will be described below, the risk 
processor 2 is structured so as to maximise its interoperability and to 
reduce its dependency on any particular third-party package. 

The integrative risk management system 1 is preferably 
implemented as a web-based application, rather than a stand-alone 

20 executable application. This permits the client interface to be within a Web 
browser in which case the client side of the risk management system 
requires no special technology beyond a standard web browser. This is 
particularly beneficial in large-scale systems where there may be large 
numbers of workstations to be integrated into the system as the use of a 

25 web-based browser avoids the need to set-up and maintain client based 
software on all the workstations. 

The risk register and analysis functions, implemented in the risk 
processor 2, are organised into a series of layers as illustrated in Figure 3. 
The purpose of this is to separate the different functionalities of 

30 presentation (GUI) 9, business logic 10 (risk management services), data 
store access 1 1 and interface services 12, 13, 14, 15, 16. This allows the 
business logic 10 to be preserved while porting one or more of the user 



interface 9, the data store access 1 1 and the external interlaces 12, 13, 14, 
15,16 to alternative technologies. The interface between each group of 
functionalities is in the form of component method invocations, with the 
interfaces between the layers being restricted to immediately adjacent 
5 layers. For example, functions in the presentation layer 9 may call 

functions in the risk management layer 10 but may not directly call to the 
lower layers which interface with external applications or the data access 
layer 1 1 . 

The presentation layer 9 consists of the instructions for the 
10 presentation of risk management information in GUI form. The 

presentation layer 9 handles input to and output from the risk management 
services layer 10 and also performs formatting and validation on the input 
and output fields. In a preferred form of the risk management system, the 
presentation layer 9 is implemented partly in HTML, or another of the mark- 
15 up languages, which the user sees, and associated client-side scripting, 
and partly by server-side ASP scripts that generate the HTML commands. 

The risk management services 10 implement the core business logic 
of the risk management system. Functions in this layer correspond closely 
to the functions, that shall be described in greater detail below, of a 
20 conventional risk management system such as the addition and removal of 
risks, the display of information concerning a specific risk etc. These 
functions embody the business logic of the system, for example the way 
risk scoring calculations are performed as well as the ability to add, remove 
or modify risks. 

25 The risk management functions are not able to access external 

systems (such as the project planning application) directly. Instead, 
interface functions are used. This isolates the core business logic from the 
concrete details of the various external applications with which the risk 
management system integrates. This means that changes to the external 

30 applications should not affect the risk management functions of layer 10, as 
any such changes are instead accommodated by the relevant interface. 
The risk management services 10 are able to access the data store by 
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means of the data store access 1 1 so that risk data is stored in the 
database. 

The first of the interfaces is an e-mail interface 12 which enables the 
risk management system to interact with users via e-mail using the 
5 communications applications 6. Such interactions may involve the 
notification to a user of risk or action assignments. The integrative risk 
management system provides an additional separate route for 
communicating with users via e-mail which shall be described in greater 
detail below. 

10 The second of the interfaces is the project planning interface 13 

which provides the interface to the external project planning functions 4. 
The project planning interface 13 enables the importation of work 
breakdown structures (as will be described below), the export of actions 
that are identified during the risk mitigation process and the processing of 

15 changes in the project plan. 

The third of the interfaces is the reporting interface 14 which 
provides the ability to launch reports using external reporting applications 7. 
This mainly involves launching the reporting package and passing the 
necessary parameters to the control filtering, sorting etc. The actual 

20 generation and formatting of reports is performed by the external reporting 
applications package 7 against the contents of the data store 3. 

Security services 15 provide authorisation facilities, governing the 
functions and data which are accessible to the user. The security is 
implemented through a combination of environment features and 

25 application logic. In the client-sen/er environment, which is the preferred 
environment for the risk management system, the security has three main 
aspects: authentication which ensures only valid clients are allowed to 
connect to the application; authorisation which ensures that clients are only 
allowed to perform authorised operations; and encryption, where needed. 

30 Such security provisions are well known and may be implemented through 
the operating platform of the risk management system. 

The data access services 1 1 provide an access layer to the risk 
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management database 3. This is preferably a generic interface througli 
wfiich to retrieve and update data but which acts to insulate the 
functionalities, that interface with the data access sen/ices, from the details 
of the physical database. 
5 As mentioned above, the system architecture for the risk 

management system is ideally a three-tier, web-based client-sen/er system 
as illustrated in Figure 4. With this architecture the interface between the 
client 17 and the server 18 is based on standard HTML. Using ASP 19, 
web pages are dynamically generated to display the appropriate user 
1 0 interface as the client moves through the application. As mentioned earlier, 
no special technology is required on the client side apart from a standard 
web browser. 

On the server side, the ASP scripts make use of a suite of COM 
components, which make up the bulk of the risk management system 

15 which, as mentioned above, is structured in a number of layers. At the 
lowest layer 1 1 , the components access an SQL server database 20 via 
ODBC. All of the server side components preferably run within the 
framework of MTS which provides transactional control for all service calls 
and so allows the components to be distributed across multiple machines, if 

20 required. Although the transactional framework extends to the ASP scripts 
as well as to the installed COM components with MTS, so that transactions 
could be handled within ASP script, it is preferred that all transactions be 
handled within the top-level components of the business logic layer 10. 
This ensures that if, at any time, the ASP layer were to be replaced with an 

25 alternative GUI, the components in the business logic layer would retain 
their integrity. With MTS it is additionally possible to implement features 
such as 'object pooling' in the architecture of the client-server network. 

Connection between the server and a browser based client 
workstation may conveniently utilise the HTTP connection with a TCP/IP 

30 connection for ODBC access where the client workstation is running a 

project management system such as MS Project. Thus, integration of the 
project management system with the risk management system can be 



achieved. The relationship between the project management system and 
the risk management system is described more fully below. 

It should be noted that in order for the system to operate efficiently 
and to maximise throughput it is preferable for the relationship between 
5 client and server to be stateless. Conveniently the HTTP protocol provides 
a stateless relationship but this can be problematic where it is highly likely 
that almost always some state will need to be maintained from one page to 
the next. This is preferably achieved through the use of additional URL 
parameters and/or hidden HTML fields. However an alternative approach 
10 would include the use of cookies. Although of more relevance where the 
client and server are separated across a network, the adoption of a 
stateless relationship between client and server in a web server 
environment where the client and server are on the same machine is still 
preferable. 

15 Integration with the project management system MS Project may be 

achieved through the use of a DBMS interface. This enables the risk 
management system 1 to directly read and update the underlying tables 
which store the project plan. The read interface allows MS Project plans, 
summary tasks and tasks to be linked in via the mapping table to form the 

20 activity breakdown structure. The update interface is used to insert 

mitigating actions back into the project plan. The MS Project plans can be 
stored in the same physical database as the risk management tables. This 
simplifies coding within the data access layer and enables queries to be 
performed spanning both the project management data and the risk 

25 management data. However, it is not essential for both sets of data to be 
stored in the same physical database and instead the project management 
data could be stored in a separate database remote from the risk 
management database. As mentioned earlier, where the MTS framework 
is adopted, distributed transactions across two or more databases can be 

30 performed where necessary. This is particularly important where different 
project management systems are implemented at different remote sites. 
Earlier it was mentioned that changes to the project management 
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data could be detected through a mapping table. Additionally, in the case 
of MS Project triggers can be added to the project database. When an 
event is triggered as a result of a change to the project database, the 
project plan is checked to establish whether the plan is one that has been 
5 imported into the risk management system. If not, no further action is 

taken. If the plan is one that has been imported then a row is inserted into 
"^the risk event queue which is allocated a unique identification code and 
whatever additional information is required to identify the event to be 
processed. Periodically the risk management system then polls the event 

10 queue to check for new events and where a new event is detected the risk 
management system determines the appropriate action to be taken e.g. to 
add or.dejete a project task. 

The risk management system 1 is also capable of integrating with 
requirements management applications such as QSS DOORS. 

15 Requirements can either be defined locally with the risk management 

system or can be imported from the requirements management application. 
In the case of QSS DOORS, integration is performed using an 
import/export protocol for example using a comma separated variables 
(CSV) file as the current version of QSS DOORS holds data in a 

20 proprietary repository format. 

Although reference has been made herein to the project 
management application MS Project, the integrative risk management 
system is intended to integrate with many different project management 
systems including but not limited to MS Project™, Primavera™ and 

25 Artemis™. Additionally, although reference is made herein to messages 
being sent by the risk management system by e-mail, it will be apparent 
that other forms of automated messaging may alternatively be implemented 
including but not limited to SMS. pager and WAP communication. . 
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CLAIMS 



1 . Risk management software comprising a set of instructions for the 
following steps to be performed when the software is executed: 

5 e) accessing project data consisting of a plurality of actions to be 

performed; 

f) analysing the project data to identify a plurality of activities to at 
least some of which is assigned at least one risk indicator; 

g) on the basis of one or more mitigating tasks identified to reduce 
10 or prevent a risk or the consequences of a risk, outputting to the 

project data one or more new actions or alterations to existing 
actions in the project data; and 

h) accessing changes to the project data and revising the plurality 
of activities in dependence on whether the changes are to 

15 actions in the project data resulting from step c) above. 

2. Risk management software as claimed in claim 1 , wherein the 
changes to the project data are compared with new actions or alterations to 
existing actions previously output to the project data and where the 

20 changes to project data relate to actions previously output to the project 
data no revisions are made to the plurality of activities. 

3. Risk management software as claimed in either of claims 1 or 2, 
comprising the step of receiving a trigger from the product data when the 

25 project data has been changed. 

4. Risk management software as claimed in either of claims 1 or 2, 
comprising the step of periodically polling the project data to determine 
whether changes have been made to the project data. 

30 

5. Risk management software as claimed in any one of the preceding 
claims, comprising the further step of automatically outputting a message to 
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a predetermined recipient when the consequences of a risk are identified 
as exceeding a selected threshold. 

6. Risk management software as claimed in any one of the preceding 

5 claims, comprising the further step of automatically outputting a message to 
one or more predetermined recipients when the processor receives notice 
of an impacted risk. 

7. Risk management software as claimed in any one of the preceding 
10 claims, comprising the further step of identifying from the plurality of 

activities one or more mitigating tasks. 

8. Risk management software as claimed in any one of the preceding 
claims, wherein the risk indicator consists of one or more of a cost 

15 allowance and a time allowance. 

9. Risk management apparatus comprising a risk processor; means for 
linking the risk processor to a risk data store; a project data interface for 
linking the risk processor to a second store containing project data; and a 

20 program store containing a set of instructions for performing the following 
functions: 

e) accessing project data in the second store, the project data 
consisting of a plurality of actions to be performed; 

f) analysing the project data to identify a plurality of activities to at 
25 least some of which is assigned at least one risk indicator and 

storing the plurality of activities in the risk data store; 

g) on the basis of one or more mitigating tasks identified to reduce 
or prevent a risk or the consequences of a risk, outputting to the 
second store one or more new actions or alterations to existing 

30 actions in the project data; and 

h) accessing changes to the project data and revising the plurality 
of activities stored in the risk data store in dependence on 
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whether the changes are to actions in the project data resulting 
from step c) above. 

10. Risk management apparatus as claimed in claim 9, wherein the risk 
data store and the second store utilise the same database. 

1 1 . Risk management apparatus as claimed in claim 9, further 
comprising a network interface for connecting to the second store when 
located at a remote site. 



12. Risk management apparatus as claimed in any one of claims 9 to 
1 1 , wherein the functionality of the apparatus is divided into at least three 
parts: a presentational part for managing the presentation of risk 
information to a user of the apparatus; a logic part for analysing the project 
1 5 data and for generating and updating the contents of the risk data store; 
and an interface part for enabling communication of the apparatus with 
external applications and wherein the presentational part and the interface 
part are restricted to only interfacing internally with the logic part. 

20 13. Risk management apparatus as claimed in claim 12, wherein the 
apparatus includes a fourth part consisting of a risk data store interface 
which is permitted to interface with both the logic part and the interface 
part. 

25 14. A risk management method for storing and updating nsk information, 
comprising the steps of: 

e) accessing project data consisting of a plurality of actions to be 
performed; 

f) analysing the project data to identify a plurality of activities to at 
30 least some of which is assigned at least one risk indicator; 

g) on the basis of one or more mitigating tasks identified to reduce 
or prevent a risk or the consequences of a risk, outputting to the 
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project data one or more new actions or alterations to existing 
actions in the project data; and 
h) accessing changes to the project data and revising the plurality 
of activities in dependence on whether the changes are to 
actions in the project data resulting from step c) above. 
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